Compilation of transformation in recalculation user interface

ABSTRACT

The compilation of a transformation chain of a recalculation user interface that displays an electronic canvas that contains one or more displayed result of a transformation chain. The transformation chain includes transforms between a respective data source and data sink. User editing of the recalculation user interface could cause one or more of the transforms to be re-executed, thereby causing recalculation. The compilation involves analyzing the transformation chain of the recalculation user interface for dependencies to create a dependency graph of dependencies between entities. For instance, some dependencies might be between entities so as to indicate that if one entity is evaluated, then the other should be also. The dependency graph is then used to create a lower level of execution steps. The dependency graph is further provided to a runtime for the program, so that the dependency graph may be available during operation of the recalculation user interface.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/862,277 filed on Apr. 12, 2013, entitled “COMPILATION OFTRANSFORMATION IN RECALCULATION USER INTERFACE,” which issued as U.S.Pat. No. ______. on ______, and which application is expresslyincorporated herein by reference in its entirety.

BACKGROUND

A “recalculation document” is an electronic document that shows variousdata sources and data sinks, and allows for a declarative transformationbetween a data source and a data sink. For any given set oftransformations interconnecting various data sources and data sinks, theoutput of the data source may be consumed by the data sink, or theoutput of the data source may be subject to transformations prior tobeing consumed by the data sink. These various transformations areevaluated resulting in one or more outputs represented throughout therecalculation document.

The user can add and edit the declarative transformations without havingin-depth knowledge of coding. Such editing automatically causes thetransformations to be recalculated, causing a change in one of moreoutputs.

A specific example of a recalculation document is a spreadsheetdocument, which includes a grid of cells. Any given cell might includean expression that is evaluated to output a particular value that isdisplayed in the cell. The expression might refer to a data source, suchas one or more other cells or values.

BRIEF SUMMARY

At least some embodiments described herein relate to the compilation ofa transformation chain of a recalculation user interface. Thetransformation chain includes a declarative transforms between arespective data sources and data sinks. For instance, in the context ofa spreadsheet, the data sink might be a particular spreadsheet cell, thetransformation might be the expression associated with the particularcell, and the data source might be one or more other cells or particularvalues referenced within the expression. User editing of therecalculation user interface could cause one or more of the transformsto be re-executed, thereby causing recalculation.

The compilation involves analyzing the transformation chain of therecalculation user interface for dependencies to create a dependencygraph of dependencies between entities. For instance, some dependenciesmight be between entities so as to indicate that if one entity isevaluated, then the other should be also. Other dependencies mightspecify user events upon which the evaluation of an entity depends. Thedependency graph is then used to create a lower level of executionsteps. The dependency graph is further provided to a runtime for theprogram, so that the dependency graph may be available during operationof the recalculation user interface.

This Summary is not intended to identify key features or essentialfeatures of the claimed subject matter, nor is it intended to be used asan aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features can be obtained, a more particular descriptionof various embodiments will be rendered by reference to the appendeddrawings. Understanding that these drawings depict only sampleembodiments and are not therefore to be considered to be limiting of thescope of the invention, the embodiments will be described and explainedwith additional specificity and detail through the use of theaccompanying drawings in which:

FIG. 1 abstractly illustrates a computing system in which someembodiments described herein may be employed;

FIG. 2 abstractly illustrates an example recalculation user interface,which illustrates several data sources and data sinks with interveningtransforms, and is used as a specific example provided to explain thebroader principles described herein;

FIG. 3 illustrates an example compilation environment that includes acompiler that accesses the transformation chain and produces compiledcode as well as a dependency chain; and

FIG. 4 illustrates a flowchart of a method for compiling atransformation chain of a recalculation user interface;

FIG. 5 illustrates an environment in which the principles of the presentinvention may be employed including a data-driven composition frameworkthat constructs a view composition that depends on input data;

FIG. 6 illustrates a pipeline environment that represents one example ofthe environment of FIG. 5;

FIG. 7 schematically illustrates an embodiment of the data portion ofthe pipeline of FIG. 6;

FIG. 8 schematically illustrates an embodiment of the analytics portionof the pipeline of FIG. 6; and

FIG. 9 schematically illustrates an embodiment of the view portion ofthe pipeline of FIG. 6.

DETAILED DESCRIPTION

At least some embodiments described herein relate to the compilation ofa transformation chain of a recalculation user interface. Therecalculation user interface might be, for example, a recalculationdocument, such as a spreadsheet. However, the recalculation userinterface may be any displayed electronic canvas that includes one ormore displayed results of a transformation chain. The transformationchain includes a plurality of transforms between a respective datasource and data sink. User editing of the recalculation user interfacecould cause one or more of the transforms to be re-executed, therebycausing recalculation.

The compilation involves analyzing the transformation chain of therecalculation user interface for dependencies to create a dependencygraph of dependencies between entities. For instance, some dependenciesmight be between entities so as to indicate that if one entity isevaluated, then the other should be also. The dependency graph is thenused to create a lower level of execution steps. The dependency graph isfurther provided to a runtime for the program, so that the dependencygraph may be available during operation of the recalculation userinterface.

Some introductory discussion of a computing system will be describedwith respect to FIG. 1. Then, the compiling of the transformation chainof the recalculation user interface will be described with respect tosubsequent figures.

Computing systems are now increasingly taking a wide variety of forms.Computing systems may, for example, be handheld devices, appliances,laptop computers, desktop computers, mainframes, distributed computingsystems, or even devices that have not conventionally been considered acomputing system. In this description and in the claims, the term“computing system” is defined broadly as including any device or system(or combination thereof) that includes at least one physical andtangible processor, and a physical and tangible memory capable of havingthereon computer-executable instructions that may be executed by theprocessor. The memory may take any form and may depend on the nature andform of the computing system. A computing system may be distributed overa network environment and may include multiple constituent computingsystems.

As illustrated in FIG. 1, in its most basic configuration, a computingsystem 100 typically includes at least one processing unit 102 andmemory 104. The memory 104 may be physical system memory, which may bevolatile, non-volatile, or some combination of the two. The term“memory” may also be used herein to refer to non-volatile mass storagesuch as physical storage media. If the computing system is distributed,the processing, memory and/or storage capability may be distributed aswell. As used herein, the term “executable module” or “executablecomponent” can refer to software objects, routings, or methods that maybe executed on the computing system. The different components, modules,engines, and services described herein may be implemented as objects orprocesses that execute on the computing system (e.g., as separatethreads).

In the description that follows, embodiments are described withreference to acts that are performed by one or more computing systems.If such acts are implemented in software, one or more processors of theassociated computing system that performs the act direct the operationof the computing system in response to having executedcomputer-executable instructions. For example, such computer-executableinstructions may be embodied on one or more computer-readable media thatform a computer program product. An example of such an operationinvolves the manipulation of data. The computer-executable instructions(and the manipulated data) may be stored in the memory 104 of thecomputing system 100. Computing system 100 may also containcommunication channels 108 that allow the computing system 100 tocommunicate with other message processors over, for example, network110. The computing system 100 also includes a display 112, which may beused to display visual representations to a user.

Embodiments described herein may comprise or utilize a special purposeor general-purpose computer including computer hardware, such as, forexample, one or more processors and system memory, as discussed ingreater detail below. Embodiments described herein also include physicaland other computer-readable media for carrying or storingcomputer-executable instructions and/or data structures. Suchcomputer-readable media can be any available media that can be accessedby a general purpose or special purpose computer system.Computer-readable media that store computer-executable instructions arephysical storage media. Computer-readable media that carrycomputer-executable instructions are transmission media. Thus, by way ofexample, and not limitation, embodiments of the invention can compriseat least two distinctly different kinds of computer-readable media:computer storage media and transmission media.

Computer storage media includes RAM, ROM, EEPROM, CD-ROM or otheroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other tangible medium which can be used to store desiredprogram code means in the form of computer-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer.

A “network” is defined as one or more data links that enable thetransport of electronic data between computer systems and/or modulesand/or other electronic devices. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or a combination of hardwired or wireless) to acomputer, the computer properly views the connection as a transmissionmedium. Transmissions media can include a network and/or data linkswhich can be used to carry or desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computer. Combinationsof the above should also be included within the scope ofcomputer-readable media.

Further, upon reaching various computer system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission media to computerstorage media (or vice versa). For example, computer-executableinstructions or data structures received over a network or data link canbe buffered in RAM within a network interface module (e.g., a “NIC”),and then eventually transferred to computer system RAM and/or to lessvolatile computer storage media at a computer system. Thus, it should beunderstood that computer storage media can be included in computersystem components that also (or even primarily) utilize transmissionmedia.

Computer-executable instructions comprise, for example, instructions anddata which, when executed at a processor, cause a general purposecomputer, special purpose computer, or special purpose processing deviceto perform a certain function or group of functions. The computerexecutable instructions may be, for example, binaries, intermediateformat instructions such as assembly language, or even source code.Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, pagers, routers, switches, and the like. The invention may also bepracticed in distributed system environments where local and remotecomputer systems, which are linked (either by hardwired data links,wireless data links, or by a combination of hardwired and wireless datalinks) through a network, both perform tasks. In a distributed systemenvironment, program modules may be located in both local and remotememory storage devices.

In this description and in the claims, a “recalculation user interface”is an interface with which a user may interact and which occurs in anenvironment in which there are one or more data sources and one or moredata sinks. Furthermore, there is a set of transformations that may eachbe declaratively defined between one or more data sources and a datasink. For instance, the output of one data source is fed into thetransformation, and the result from the transformation is then providedto the data sink, resulting in potentially some kind of change invisualization to the user.

The transformations are “declarative” in the sense that a user withoutspecific coding knowledge can write the declarations that define thetransformation. As the transformation is declaratively defined, a usermay change the declarative transformation. In response, a recalculationis performed, resulting in perhaps different data being provided to thedata sinks.

A classic example of a recalculation user interface is a spreadsheetdocument. A spreadsheet document includes a grid of cells. Initially,the cells are empty, and thus any cell of the spreadsheet program hasthe potential to be a data source or a data sink, depending on themeaning and context of declarative expressions inputted by a user. Forinstance, a user might select a given cell, and type an expression intothat cell. The expression might be as simple as an expressed scalarvalue to be assigned to that cell. That cell may later be used as a datasource. Alternatively, the expression for a given cell might be in theform of an equation in which input values are taken from one or moreother cells. In that case, the given cell is a data sink that displaysthe result of the transformation. However, during continued authoring,that cell may be used as a data sink for yet other transformationsdeclaratively made by the author.

The author of a spreadsheet document need not be an expert on imperativecode. The author is simply making declarations that define atransformation, and selecting corresponding data sinks and data sources.FIGS. 5 through 9 described hereinafter provide a more generalizeddeclarative authoring environment in which a more generalizedrecalculation user interface is described. In that subsequentlydescribed environment, visualized controls may serve as both datasources and data sinks. Furthermore, the declarative transformations maybe more intuitively authored by simple manipulations of those controls.

FIG. 2 abstractly illustrates an example recalculation user interface200, which is a specific example provided to explain the broaderprinciples described herein. The recalculation user interface 200 isjust an example as the principles describe herein may be applied to anyrecalculation user interface to create a countless variety ofrecalculation user interfaces for a countless variety of applications.

The recalculation user interface 200 includes several declarativetransformations 211 through 215. The dashed circle around each of thearrows representing the transformations 211 through 215 symbolizes thatthe transformations are each in declarative form.

In this specific example of FIG. 2, the transform 211 includesrespective data source 201 and data sink 202. Note that a data sink forone transform may also be a data source for another transform. Forinstance, data sink 202 for transform 211 also serves as a data sourcefor the transform 212. Furthermore, a transform may have multiple datasources. Thus, the transform chain can be made hierarchical, and thusquite complex. For instance, the transform 212 includes data source 202and data sink 203. The data sink 203 includes two data sources; namelydata source 202 for transform 212, and data source 205 for transform214. That said, perhaps a single transform leads the two data sources202 and 205 into the data sink 203. The transform 213 includes a datasource 204 and a data sink 205.

If the recalculation user interface were a spreadsheet document, forexample, the various data sources/sinks 201 through 205 might bespreadsheet cells, in which case the transforms represent the expressionthat would be associated with each data sink. The output of eachexpression is displayed within the cell. Thus, in the case of aspreadsheet, the data sources/sinks might be complex visualized controlsthat include both input parameters to and output parameters from thetransformation chain. For instance, in FIG. 2, there is an additionaldeclarative transformation 215 that leads from data source 205 into datasink 201. Thus, the data source/sink 201 might visualize informationrepresenting an output from transform 215, as well as provide furtherdata to other data sinks.

Recalculation user interfaces do not need to have visualizationcontrols. One example of this is a recalculation user interface meant toperform a transformation-based computation, consuming source data andupdating sink data, with no information displayed to the user about thecomputation in the normal case. For instance, the recalculation userinterface might support a background computation. A second example is arecalculation user interface that has output controls that operateexternal actuators, such as the valves in a process control example.Such controls are like display controls in that their states arecontrolled by results of the transformation computation and on signalinputs. However, here, the output is a control signal to a device ratherthan a visualization to a display. Consider, for example, arecalculation user interface for controlling a robot. This recalculationuser interface might have rules for robot actions and behavior thatdepend on robot sensor inputs like servo positions and speeds,ultrasonic range-finding measurements, and so forth. Or consider aprocess control application based on a recalculation user interface thattakes signals from equipment sensors like valve positions, fluid flowrates, and so forth.

FIG. 3 illustrates an example compilation environment 300 that includesa compiler 310 that accesses the transformation chain 301. An example,of the transformation chain 301 is the recalculation user interface 200of FIG. 2. FIG. 4 illustrates a flowchart of a method 400 for compilinga transformation chain of a recalculation user interface. The method 400may be performed by the compiler 310 of FIG. 3. In one embodiment, themethod 400 may be performed by the computing system 100 in response tothe processor(s) 102 executing computer-executable instructions embodiedon one or more computer-readable storage media.

The method 400 includes analyzing a transformation chain of therecalculation user interface for dependencies (act 401). For instance,referring to FIG. 2, the compiler 300 might analyze each of thetransformations 211 through 215. The transformations are declarative andthus the dependencies can be extracted more easily than they could ifthe transformations were expressed using an imperative computerlanguage.

Based on the analysis, a dependency graph is created (act 402) betweenentities referenced in the transformations. Essentially, thedependencies have a source entity that represents an event, and a targetentity that represents that the evaluation of that target entity dependson the event. An example of the event might be a user event in which theuser interacts in a certain way with the recalculation user interface.As another example, the event might be an inter-entity event in which ifthe source entity is evaluated, then the target entity of the dependencyshould also be evaluated.

The compiler then creates lower-level execution steps based on thedependency graph (act 403). The lower-level execution steps might be,for instance, imperative language code. Imperative language code isadapted to respond to detect events, reference an event chart todetermine a function to execute, and execute that function. Accordingly,each of the dependencies in the dependency graph may be reduced to afunction. The dependency graph itself may be provided to the runtime(act 404). The imperative language code may be, for example, a scriptlanguage, such as JAVASCRIPT. However, the principles described hereinare not limited to the imperative language code being of any particularlanguage.

As an example, FIG. 3 illustrates that the compiler 310 generateslower-level code 311 as well. Such lower level code 311 includes acompilation of each of the transformations in the transformation chain.For instance, lower level code 311 is illustrated as including element321 representing the compilation of each of the transformations in thetransformation chain. In the context of FIG. 2, the element 321 wouldinclude a compilation of each of the transformations 211 through 215.The lower level code 311 also includes a variety of functions 322. Afunction is generated for each dependency in the dependency graph. Thefunctions may be imperative language functions.

When the imperative language runtime detects an event that is listed inthe dependency graph, the corresponding function within the compiledfunctions 322 is also executed. Accordingly, with all transformationsbeing properly compiled, and with each of the dependencies on particularevents being enforced by dedicated functions, the declarativerecalculation user interface is properly represented as an imperativelanguage code.

Accordingly, an effective mechanism has been described for compiling adeclarative recalculation user interface. In addition, the runtime isprovided with a dependency graph, rather than a more extensiveinterpreter.

A specific example of an authoring pipeline for allowing non-programmersto author programs having complex behaviors using a recalculation userinterface will now be described with respect to FIGS. 5 through 9.

FIG. 5 illustrates a visual composition environment 500 that may be usedto construct an interactive visual composition in the form of arecalculation user interface. The construction of the recalculation userinterface is performed using data-driven analytics and visualization ofthe analytical results. The environment 500 includes a compositionframework 510 that performs logic that is performed independent of theproblem-domain of the view composition 530. For instance, the samecomposition framework 510 may be used to compose interactive viewcompositions for city plans, molecular models, grocery shelf layouts,machine performance or assembly analysis, or other domain-specificrenderings.

The composition framework 510 uses domain-specific data 520, however, toconstruct the actual visual composition 530 that is specific to thedomain. Accordingly, the same composition framework 510 may be used togenerate recalculation user interfaces for any number of differentdomains by changing the domain-specific data 520, rather than having torecode the composition framework 510 itself. Thus, the compositionframework 510 of the pipeline 500 may apply to a potentially unlimitednumber of problem domains, or at least to a wide variety of problemdomains, by altering data, rather than recoding and recompiling. Theview composition 530 may then be supplied as instructions to anappropriate 2-D or 3-D rendering module. The architecture describedherein also allows for convenient incorporation of pre-existing viewcomposition models as building blocks to new view composition models. Inone embodiment, multiple view compositions may be included in anintegrated view composition to allow for easy comparison between twopossible solutions to a model.

FIG. 6 illustrates an example architecture of the composition framework510 in the form of a pipeline environment 600. The pipeline environment600 includes, amongst other things, the pipeline 601 itself. Thepipeline 601 includes a data portion 610, an analytics portion 620, anda view portion 630, which will each be described in detail with respectto subsequent FIGS. 7 through 9, respectively, and the accompanyingdescription. For now, at a general level, the data portion 610 of thepipeline 601 may accept a variety of different types of data andpresents that data in a canonical form to the analytics portion 620 ofthe pipeline 601. The analytics portion 620 binds the data to variousmodel parameters, and solves for the unknowns in the model parametersusing model analytics. The various parameter values are then provided tothe view portion 630, which constructs the composite view using thosevalues of the model parameters.

The pipeline environment 600 also includes an authoring component 640that allows an author or other user of the pipeline 601 to formulateand/or select data to provide to the pipeline 601. For instance, theauthoring component 640 may be used to supply data to each of dataportion 610 (represented by input data 611), analytics portion 620(represented by analytics data 621), and view portion 630 (representedby view data 631). The various data 611, 621 and 631 represent anexample of the domain-specific data 520 of FIG. 5, and will be describedin much further detail hereinafter. The authoring component 640 supportsthe providing of a wide variety of data including for example, dataschemas, actual data to be used by the model, the location or range ofpossible locations of data that is to be brought in from externalsources, visual (graphical or animation) objects, user interfaceinteractions that can be performed on a visual, modeling statements(e.g., views, equations, constraints), bindings, and so forth. In oneembodiment, the authoring component is but one portion of thefunctionality provided by an overall manager component (not shown inFIG. 6, but represented by the composition framework 510 of FIG. 5). Themanager is an overall director that controls and sequences the operationof all the other components (such as data connectors, solvers, viewers,and so forth) in response to events (such as user interaction events,external data events, and events from any of the other components suchas the solvers, the operating system, and so forth).

In the pipeline environment 600 of FIG. 6, the authoring component 640is used to provide data to an existing pipeline 601, where it is thedata that drives the entire process from defining the input data, todefining the analytical model (referred to above as the “transformationchain”), to defining how the results of the transformation chain arevisualized in the view composition. Accordingly, one need not performany coding in order to adapt the pipeline 601 to any one of a widevariety of domains and problems. Only the data provided to the pipeline601 is what is to change in order to apply the pipeline 601 to visualizea different view composition either from a different problem domainaltogether, or to perhaps adjust the problem solving for an existingdomain. Further, since the data can be changed at use time (i.e., runtime), as well as at author time, the model can be modified and/orextended at runtime. Thus, there is less, if any, distinction betweenauthoring a model and running the model. Because all authoring involvesediting data items and because the software runs all of its behaviorfrom data, every change to data immediately affects behavior without theneed for recoding and recompilation.

The pipeline environment 600 also includes a user interaction responsemodule 650 that detects when a user has interacted with the displayedview composition, and then determines what to do in response. Forexample, some types of interactions might require no change in the dataprovided to the pipeline 601 and thus require no change to the viewcomposition. Other types of interactions may change one or more of thedata 611, 621, or 631. In that case, this new or modified data may causenew input data to be provided to the data portion 610, might require areanalysis of the input data by the analytics portion 620, and/or mightrequire a re-visualization of the view composition by the view portion630.

Accordingly, the pipeline 601 may be used to extend data-drivenanalytical visualizations to perhaps an unlimited number of problemdomains, or at least to a wide variety of problem domains. Furthermore,one need not be a programmer to alter the view composition to address awide variety of problems. Each of the data portion 610, the analyticsportion 620 and the view portion 630 of the pipeline 601 will now bedescribed with respect to respective data portion 700 of FIG. 7, theanalytics portion 800 of FIG. 8, and the view portion 900 of FIG. 9, inthat order. As will be apparent from FIGS. 7 through 9, the pipeline 601may be constructed as a series of transformation component where theyeach 1) receive some appropriate input data, 2) perform some action inresponse to that input data (such as performing a transformation on theinput data), and 3) output data which then serves as input data to thenext transformation component.

FIG. 7 illustrates just one of many possible embodiments of a dataportion 700 of the pipeline 601 of FIG. 6. One of the functions of thedata portion 700 is to provide data in a canonical format that isconsistent with schemas understood by the analytics portion 800 of thepipeline discussed with respect to FIG. 8. The data portion includes adata access component 710 that accesses the heterogenic data 701. Theinput data 701 may be “heterogenic” in the sense that the data may (butneed not) be presented to the data access component 710 in a canonicalform. In fact, the data portion 700 is structured such that theheterogenic data could be of a wide variety of formats. Examples ofdifferent kinds of domain data that can be accessed and operated on bymodels include text and XML documents, tables, lists, hierarchies(trees), SQL database query results, BI (business intelligence) cubequery results, graphical information such as 2D drawings and 3D visualmodels in various formats, and combinations thereof (i.e, a composite).Further, the kind of data that can be accessed can be extendeddeclaratively, by providing a definition (e.g., a schema) for the datato be accessed. Accordingly, the data portion 700 permits a wide varietyof heterogenic input into the model, and also supports runtime,declarative extension of accessible data types.

In one embodiment, the data access portion 700 includes a number ofconnectors for obtaining data from a number of different data sources.Since one of the primary functions of the connector is to placecorresponding data into canonical form, such connectors will often bereferred to hereinafter and in the drawings as “canonicalizers”. Eachcanonicalizer might have an understanding of the specific ApplicationProgram Interfaces (API's) of its corresponding data source. Thecanonicalizer might also include the corresponding logic for interfacingwith that corresponding API to read and/or write data from and to thedata source. Thus, canonicalizers bridge between external data sourcesand the memory image of the data.

The data access component 710 evaluates the input data 701. If the inputdata is already canonical and thus processable by the analytics portion800, then the input data may be directly provided as canonical data 740to be input to the analytics portion 800.

However, if the input data 701 is not canonical, then the appropriatedata canonicalization component 730 is able to convert the input data701 into the canonical format. The data canonicalization components 730are actually a collection of data canonicalization components 730, eachcapable of converting input data having particular characteristics intocanonical form. The collection of canonicalization components 730 isillustrated as including four canonicalization components 731, 732, 733and 734. However, the ellipses 735 represents that there may be othernumbers of canonicalization components as well, perhaps even fewer thatthe four illustrated.

The input data 701 may even include a canonicalizer itself as well as anidentification of correlated data characteristic(s). The data portion700 may then register the correlated data characteristics, and providethe canonicalization component to the data canonicalization componentcollection 730, where it may be added to the available canonicalizationcomponents. If input data is later received that has those correlatedcharacteristics, the data access component 710 may then assign the inputdata to the correlated canonicalization component. Canonicalizationcomponents can also be found dynamically from external sources, such asfrom defined component libraries on the web. For example, if the schemafor a given data source is known but the needed canonicalizer is notpresent, the canonicalizer can be located from an external componentlibrary, provided such a library can be found and contains the neededcomponents. The pipeline might also parse data for which no schema isyet known and compare parse results versus schema information in knowncomponent libraries to attempt a dynamic determination of the type ofthe data, and thus to locate the needed canonicalizer components.

Alternatively, instead of the input data including all of thecanonicalization component, the input data may instead provide atransformation definition defining canonicalization transformations. Thecollection 730 may then be configured to convert that transformationsdefinition into a corresponding canonicalization component that enforcesthe transformations along with zero or more standard defaultcanonicalization transformation. This represents an example of a case inwhich the data portion 700 consumes the input data and does not providecorresponding canonicalized data further down the pipeline. In perhapsmost cases, however, the input data 701 results in correspondingcanonicalized data 740 being generated.

In one embodiment, the data access component 710 may be configured toassign input data to the data canonicalization component on the basis ofa file type and/or format type of the input data. Other characteristicsmight include, for example, a source of the input data. A defaultcanonicalization component may be assigned to input data that does nothave a designated corresponding canonicalization component. The defaultcanonicalization component may apply a set of rules to attempt tocanonicalize the input data. If the default canonicalization componentis not able to canonicalize the data, the default canonicalizationcomponent might trigger the authoring component 540 of FIG. 5 to promptthe user to provide a schema definition for the input data. If a schemadefinition does not already exist, the authoring component 540 mightpresent a schema definition assistant to help the author generate acorresponding schema definition that may be used to transform the inputdata into canonical form. Once the data is in canonical form, the schemathat accompanies the data provides sufficient description of the datathat the rest of the pipeline 601 does not need new code to interpretthe data. Instead, the pipeline 601 includes code that is able tointerpret data in light of any schema that is expressible as anaccessible schema declaration language.

Regardless, canonical data 740 is provided as output data from the dataportion 700 and as input data to the analytics portion 800. Thecanonical data might include fields that include a variety of datatypes. For instance, the fields might includes simple data types such asintegers, floating point numbers, strings, vectors, arrays, collections,hierarchical structures, text, XML documents, tables, lists, SQLdatabase query results, BI (business intelligence) cube query results,graphical information such as 2D drawings and 3D visual models invarious formats, or even complex combinations of these various datatypes. As another advantage, the canonicalization process is able tocanonicalize a wide variety of input data. Furthermore, the variety ofinput data that the data portion 700 is able to accept is expandable.This is helpful in the case where multiple models are combined as willbe discussed later in this description.

FIG. 8 illustrates analytics portion 800 which represents an example ofthe analytics portion 620 of the pipeline 601 of FIG. 6. The dataportion 700 provided the canonicalized data 801 to the data-modelbinding component 810. While the canonicalized data 801 might have anycanonicalized form, and any number of parameters, where the form andnumber of parameters might even differ from one piece of input data toanother. For purposes of discussion, however, the canonical data 801 hasfields 802A through 802H, which may collectively be referred to hereinas “fields 802”.

On the other hand, the analytics portion 800 includes a number of modelparameters 811. The type and number of model parameters may differaccording to the model. However, for purposes of discussion of aparticular example, the model parameters 811 will be discussed asincluding model parameters 811A, 811B, 811C and 811D. In one embodiment,the identity of the model parameters, and the analytical relationshipsbetween the model parameters may be declaratively defined without usingimperative coding.

A data-model binding component 810 intercedes between the canonicalizeddata fields 802 and the model parameters 811 to thereby provide bindingsbetween the fields. In this case, the data field 802B is bound to modelparameter 811A as represented by arrow 803A. In other words, the valuefrom data field 802B is used to populate the model parameter 811A. Also,in this example, the data field 802E is bound to model parameter 811B(as represented by arrow 803B), and data field 802H is bound to modelparameter 811C (as represented by arrow 803C).

The data fields 802A, 802C, 802D, 802F and 802G are not shown bound toany of the model parameters. This is to emphasize that not all of thedata fields from input data are always required to be used as modelparameters. In one embodiment, one or more of these data fields may beused to provide instructions to the data-model binding component 810 onwhich fields from the canonicalized data (for this canonicalized data orperhaps any future similar canonicalized data) are to be bound to whichmodel parameter. This represents an example of the kind of analyticsdata 621 that may be provided to the analytics portion 620 of FIG. 6.The definition of which data fields from the canonicalized data arebound to which model parameters may be formulated in a number of ways.For instance, the bindings may be 1) explicitly set by the author atauthoring time, 2) explicit set by the user at use time (subject to anyrestrictions imposed by the author), 3) automatic binding by theauthoring component 640 based on algorithmic heuristics, and/or 4)prompting by the authoring component of the author and/or user tospecify a binding when it is determined that a binding cannot be madealgorithmically. Thus bindings may also be resolved as part of the modellogic itself.

The ability of an author to define which data fields are mapped to whichmodel parameters gives the author great flexibility in being able to usesymbols that the author is comfortable with to define model parameters.For instance, if one of the model parameters represents pressure, theauthor can name that model parameter “Pressure” or “P” or any othersymbol that makes sense to the author. The author can even rename themodel parameter which, in one embodiment, might cause the data modelbinding component 810 to automatically update to allow bindings thatwere previously to the model parameter of the old name to instead bebound to the model parameter of the new name, thereby preserving thedesired bindings. This mechanism for binding also allows binding to bechanged declaratively at runtime.

The model parameter 811D is illustrated with an asterisk to emphasizethat in this example, the model parameter 811D was not assigned a valueby the data-model binding component 810. Accordingly, the modelparameter 811D remains an unknown. In other words, the model parameter811D is not assigned a value.

The modeling component 820 performs a number of functions. First, themodeling component 820 defines analytical relationships 821 between themodel parameters 811. The analytical relationships 821 are categorizedinto three general categories including equations 831, rules 832 andconstraints 833. However, the list of solvers is extensible. In oneembodiment, for example, one or more simulations may be incorporated aspart of the analytical relationships provided a corresponding simulationengine is provided and registered as a solver.

The term “equation” as used herein aligns with the term as it is used inthe field of mathematics.

The term “rules” as used herein means a conditional statement where ifone or more conditions are satisfied (the conditional or “if” portion ofthe conditional statement), then one or more actions are to be taken(the consequence or “then” portion of the conditional statement). A ruleis applied to the model parameters if one or more model parameters areexpressed in the conditional statement, or one or more model parametersare expressed in the consequence statement.

The term “constraint” as used herein means that a restriction is appliedto one or more model parameters. For instance, in a city planning model,a particular house element may be restricted to placement on a maplocation that has a subset of the total possible zoning designations. Abridge element may be restricted to below a certain maximum length, or acertain number of lanes.

An author that is familiar with the model may provide expressions ofthese equations, rules and constraint that apply to that model. In thecase of simulations, the author might provide an appropriate simulationengine that provides the appropriate simulation relationships betweenmodel parameters. The modeling component 820 may provide a mechanism forthe author to provide a natural symbolic expression for equations, rulesand constraints. For example, an author of a thermodynamics relatedmodel may simply copy and paste equations from a thermodynamicstextbook. The ability to bind model parameters to data fields allows theauthor to use whatever symbols the author is familiar with (such as theexact symbols used in the author's relied-upon textbooks) or the exactsymbols that the author would like to use.

Prior to solving, the modeling component 820 also identifies which ofthe model parameters are to be solved for (i.e., hereinafter, the“output model variable” if singular, or “output model variables” ifplural, or “output model variable(s)” if there could be a single orplural output model variables). The output model variables may beunknown parameters, or they might be known model parameters, where thevalue of the known model parameter is subject to change in the solveoperation. In the example of FIG. 8, after the data-model bindingoperation, model parameters 811A, 811B and 811C are known, and modelparameter 811D is unknown. Accordingly, unknown model parameter 811Dmight be one of the output model variables. Alternatively or inaddition, one or more of the known model parameters 811A, 811B and 811Cmight also be output model variables. The solver 840 then solves for theoutput model variable(s), if possible. In one embodiment describedhereinafter, the solver 840 is able to solve for a variety of outputmodel variables, even within a single model so long as sufficient inputmodel variables are provided to allow the solve operation to beperformed. Input model variables might be, for example, known modelparameters whose values are not subject to change during the solveoperation. For instance, in FIG. 8, if the model parameters 811A and811D were input model variables, the solver might instead solve foroutput model variables 811B and 811C instead. In one embodiment, thesolver might output any one of a number of different data types for asingle model parameter. For instance, some equation operations (such asaddition, subtraction, and the like) apply regardless of the whether theoperands are integers, floating point, vectors of the same, or matricesof the same.

In one embodiment, even when the solver 840 cannot solve for aparticular output model variable, the solver 840 might still present apartial solution for that output model variable, even if a full solve tothe actual numerical result (or whatever the solved-for data type) isnot possible. This allows the pipeline to facilitate incrementaldevelopment by prompting the author as to what information is needed toarrive at a full solve. This also helps to eliminate the distinctionbetween author time and use time, since at least a partial solve isavailable throughout the various authoring stages. For an abstractexample, suppose that the analytics model includes an equation a=b+c+d.Now suppose that a, c and d are output model variables, and b is aninput model variable having a known value of 5 (an integer in thiscase). In the solving process, the solver 840 is only able to solve forone of the output model variables “d”, and assign a value of 6 (aninteger) to the model parameter called “d”, but the solver 840 is notable to solve for “c”. Since “a” depends from “c”, the model parametercalled “a” also remains an unknown and unsolved for. In this case,instead of assigning an integer value to “a”, the solver might do apartial solve and output the string value of “c+11” to the modelparameter “a”. As previously mentioned, this might be especially helpfulwhen a domain expert is authoring an analytics model, and willessentially serve to provide partial information regarding the contentof model parameter “a” and will also serve to cue the author that somefurther model analytics needs to be provided that allow for the “c”model parameter to be solved for. This partial solve result may beoutput in some fashion in the view composition to allow the domainexpert to see the partial result.

The solver 840 is shown in simplified form in FIG. 8. However, thesolver 840 may direct the operation of multiple constituent solvers aswill be described with respect to FIG. 9. In FIG. 8, the modelingcomponent 820 then makes the model parameters (including the now knownand solved-for output model variables) available as output to beprovided to the view portion 900 of FIG. 9.

FIG. 9 illustrates a view portion 900 which represents an example of theview portion 630 of FIG. 6, and represents example of visualizedcontrols in the recalculation user interface 200. The view portion 900receives the model parameters 811 from the analytics portion 800 of FIG.8. The view portion also includes a view components repository 920 thatcontains a collection of view components. For example, the viewcomponents repository 920 in this example is illustrated as includingview components 921 through 924, although the view components repository920 may contain any number of view components. The view components eachmay include zero or more input parameters. For example, view component921 does not include any input parameters. However, view component 922includes two input parameters 942A and 942B. View component 923 includesone input parameter 943, and view component 924 includes one inputparameter 944. That said, this is just an example. The input parametersmay, but need not necessary, affect how the visual item is rendered. Thefact that the view component 921 does not include any input parametersemphasizes that there can be views that are generated without referenceto any model parameters. Consider a view that comprises just fixed(built-in) data that does not change. Such a view might for exampleconstitute reference information for the user. Alternatively, consider aview that just provides a way to browse a catalog, so that items can beselected from it for import into a model.

Each view component 921 through 924 includes or is associated withcorresponding logic that, when executed by the view compositioncomponent 940 using the corresponding view component input parameter(s),if any, causes a corresponding view item to be placed in virtual space950. That virtual item may be a static image or object, or may be adynamic animated virtual item or object For instance, each of viewcomponents 921 through 924 are associated with corresponding logic 931through 934 that, when executed causes the corresponding virtual item951 through 954, respectively, to be rendered in virtual space 950. Thevirtual items are illustrated as simple shapes. However, the virtualitems may be quite complex in form perhaps even including animation. Inthis description, when a view item is rendered in virtual space, thatmeans that the view composition component has authored sufficientinstructions that, when provided to the rendering engine, the renderingengine is capable if displaying the view item on the display in thedesignated location and in the designated manner.

The view components 921 through 924 may be provided perhaps even as viewdata to the view portion 900 using, for example, the authoring component640 of FIG. 6. For instance, the authoring component 640 might provide aselector that enables the author to select from several geometric forms,or perhaps to compose other geometric forms. The author might alsospecify the types of input parameters for each view component, whereassome of the input parameters may be default input parameters imposed bythe view portion 900. The logic that is associated with each viewcomponent 921 through 924 may be provided also a view data, and/or mayalso include some default functionality provided by the view portion 900itself.

The view portion 900 includes a model-view binding component 910 that isconfigured to bind at least some of the model parameters tocorresponding input parameters of the view components 921 through 924.For instance, model parameter 811A is bound to the input parameter 942Aof view component 922 as represented by arrow 911A. Model parameter 811Bis bound to the input parameter 942B of view component 922 asrepresented by arrow 911B. Also, model parameter 811D is bound to theinput parameters 943 and 944 of view components 923 and 924,respectively, as represented by arrow 911C. The model parameter 811C isnot shown bound to any corresponding view component parameter,emphasizing that not all model parameters need be used by the viewportion of the pipeline, even if those model parameters were essentialin the analytics portion. Also, the model parameter 811D is shown boundto two different input parameters of view components representing thatthe model parameters may be bound to multiple view component parameters.In one embodiment, the definition of the bindings between the modelparameters and the view component parameters may be formulated by 1)being explicitly set by the author at authoring time, 2) explicitly setby the user at use time (subject to any restrictions imposed by theauthor), 3) automatic binding by the authoring component 640 based onalgorithmic heuristics, and/or 4) prompting by the authoring componentof the author and/or user to specify a binding when it is determinedthat a binding cannot be made algorithmically.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A method for compiling a transformation chain ofa recalculation user interface, the method being implemented at acomputer system that includes one or more processors, the methodcomprising the computer system implementing the following: an act ofassigning each of a plurality of entities to one or more datacanonicalization components based on at least one detectedcharacteristic of each of the plurality of entities, respectively,wherein the one or more data canonicalization components converts theplurality of entities into a canonical format; an act of determiningdependencies between each of the plurality of canonicalized entitiesbased on the transformation chain of the recalculation user interface;an act of generating a dependency graph based on the determineddependencies; an act of generating a lower level of execution stepsbased on a data received from the dependency graph, wherein the lowerlevel of execution steps includes a compilation of each transformationin the transformation chain, and wherein the lower level of executionsteps also includes at least one dedicated function for each of thedependencies in the dependency graph; an act of providing the dependencygraph to a runtime for a program; and upon a condition in which theruntime detects an event that is listed in the dependency graph, an actof executing the corresponding at least one dedicated function.
 2. Themethod of claim 1, wherein the at least one detected characteristiccomprises a source of a corresponding entity.
 3. The method of claim 1,wherein the one or more data canonicalization components comprises aplurality of canonicalization components that each correspond to adifferent source.
 4. The method in accordance with claim 1, wherein thedependency graph includes an inter-entity dependency identification fromwhich it can be determined that if a first entity included in theplurality of entities is evaluated, then a second entity also includedin the plurality of entities is also to be evaluated.
 5. The method inaccordance with claim 1, wherein the dependency graph includes a userevent dependency from which it can be determined that if a user eventoccurs, then an entity included in the plurality of entities isevaluated.
 6. The method in accordance with claim 1, wherein therecalculation user interface is a spreadsheet document.
 7. The method inaccordance with claim 1, wherein the transformation chain is expresseddeclaratively and wherein the lower level of execution steps areexpressed in imperative language code.
 8. A computer program productcomprising one or more computer-readable hardware storage devices havingthereon computer-executable instructions that are executable by one ormore processors of a computing system to cause the computing system tocompile a transformation chain of a recalculation user interface by atleast causing the computing system to implement: an act of assigningeach of a plurality of entities to one or more data canonicalizationcomponents based on at least one detected characteristic of each of theplurality of entities, respectively, wherein the one or more datacanonicalization components converts the plurality of entities into acanonical format; an act of determining dependencies between each of theplurality of canonicalized entities based on the transformation chain ofthe recalculation user interface; an act of generating a dependencygraph based on the determined dependencies; an act of generating a lowerlevel of execution steps based on a data received from the dependencygraph, wherein the lower level of execution steps includes a compilationof each transformation in the transformation chain, and wherein thelower level of execution steps also includes at least some dedicatedfunction for each of the dependencies in the dependency graph; an act ofproviding the dependency graph to a runtime for a program; and upon acondition in which the runtime detects an event that is listed in thedependency graph, an act of executing the corresponding at least onededicated function.
 9. The computer program product of claim 8, whereinthe at least one detected characteristic comprises a source of acorresponding entity.
 10. The computer program product of claim 8,wherein the one or more data canonicalization components comprises aplurality of canonicalization components that each correspond to adifferent source.
 11. The computer program product in accordance withclaim 8, wherein the recalculation user interface is a spreadsheetdocument.
 12. The computer program product in accordance with claim 8,wherein the recalculation user interface has a complex control that hasinput parameters to and output parameters from the transformation. 13.The computer program product in accordance with claim 8, wherein theplurality of entities includes a data sink that is a control.
 14. Thecomputer program product in accordance with claim 8, wherein theplurality of entities includes a data source that is a control.
 15. Thecomputer program product in accordance with claim 8, wherein thetransformation is expressed declaratively.
 16. The computer programproduct in accordance with claim 8, wherein the transformation chain isexpressed declaratively and wherein the lower level of execution stepsare expressed in imperative language code.
 17. A computer system,comprising: one or more processors; system memory; a display device; andone or more computer-readable hardware storage devices having storedthereon computer-executable instructions that are executable by the oneor more processors to cause the computer system to compile atransformation chain of a recalculation user interface that includes oneor more controls, and further to cause the computer system to perform atleast the following: assign each of a plurality of entities to one ormore data canonicalization components based on at least one detectedcharacteristic of each of the plurality of entities, respectively,wherein the one or more data canonicalization components converts theplurality of entities into a canonical format; determine dependenciesbetween each of the plurality of canonicalized entities based on thetransformation chain of the recalculation user interface; generate adependency graph based on the determined dependencies; generate a lowerlevel of execution steps based on a data received from the dependencygraph, wherein the lower level of execution steps includes a compilationof each transformation in the transformation chain, and wherein thelower level of execution steps also includes at least one dedicatedfunction for each of the dependencies in the dependency graph; providethe dependency graph to a runtime for a program; and upon a condition inwhich the runtime detects an event that is listed in the dependencygraph, execute the corresponding at least one dedicated function. 18.The computer system in accordance with claim 17, wherein the one or moredata canonicalization components is obtained from an external componentlibrary.
 19. The computer system in accordance with claim 17, whereinthe at least one detected characteristic comprises a source of acorresponding entity and wherein the one or more data canonicalizationcomponents comprises a plurality of canonicalization components thateach correspond to a different source.
 20. The computer system inaccordance with claim 19, wherein a default data canonicalizationcomponent that is included within the one or more canonicalizationcomponents is assigned to a particular entity that does not have adesignated data canonicalization component, wherein the default datacanonicalization component uses a default set of rules to attempt tocanonicalize the particular entity, and wherein the computer-executableinstructions further cause the computer system to prompt a user of thecomputer system to provide a schema definition for the particular entityin response to detecting a condition in which the default datacanonicalization component fails to canonicalize the particular entity.